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Abstract 


This memo defines an extension of the Management Information Base 
(MIB) for use with network management protocols in TCP/IP-based 
internets. In particular, it defines objects for managing the 
insertion of interesting Circuit Interfaces into the ifTable. This 
is important for circuits that must be used within other MIB modules 
which require an ifEntry. It allows for integrated monitoring of 
circuits as well as routing to circuits using unaltered, pre-existing 
MIB modules. 
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1. The SNMP Management Framework 
The SNMP Management Framework presently consists of five major 
components: 

o An overall architecture, described in RFC 2571 [1]. 

o Mechanisms for describing and naming objects and events for the 
purpose of management. The first version of this Structure of 
Management Information (SMI) is called SMIvl and described in STD 
16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The 
second version, called SMIv2, is described in STD 58, RFC 2578 
[5], RFC 2579 [6] and RFC 2580 [7]. 

o Message protocols for transferring management information. The 
first version of the SNMP message protocol is called SNMPv1 and 
described in STD 15, RFC 1157 [8]. A second version of the SNMP 
message protocol, which is not an Internet standards track 
protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 
1906 [10]. The third version of the message protocol is called 
SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 
[12]. 

o Protocol operations for accessing management information. The 
first set of protocol operations and associated PDU formats is 
described in STD 15, RFC 1157 [8]. A second set of protocol 
operations and associated PDU formats is described in RFC 1905 
E3]: 
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o A set of fundamental applications described in RFC 2573 [14] and 
the view-based access control mechanism described in RFC 2575 
[15]. 


A more detailed introduction to the current SNMP Management Framework 
can be found in RFC 2570 [16]. 


Managed objects are accessed via a virtual information store, termed 
the Management Information Base or MIB. Objects in the MIB are 
defined using the mechanisms defined in the SMI. 


This memo specifies a MIB module that is compliant to the SMIv2. A 
MIB conforming to the SMIv1 can be produced through the appropriate 


translations. The resulting translated MIB must be semantically 
equivalent, except where objects or events are omitted because no 
translation is possible (use of Counter64). Some machine readable 


information in SMIv2 will be converted into textual descriptions in 
SMIv1 during the translation process. However, this loss of machine 
readable information is not considered to change the semantics of the 
MIB. 


2. Conventions 


The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 
they appear in this document, are to be interpreted as described in 
RFC 2119 [21]. 


3. Overview 


This MIB module addresses the concept of inserting circuits, which 
are potentially virtual, into the ifTable. There are multiple 
reasons to allow circuits to be added to the ifTable. The most 
prevalent of which are the standard routing MIB tables such as the 
ipCidrRouteTable (IP-FORWARD-MIB) and the ipNetToMediaTable (IP-MIB) 
act on the ifIndex and the RMON MIBs (RMON-MIB and RMON2-MIB as 
defined in RFC 2819 [23] and RFC 2021 [19]) require the use of an 
ifIndex a DataSource. 


There is a further need to potentially monitor or manage a circuit 
based on the directional flow of traffic going through it. For 
instance, monitoring of protocols passed on a circuit using RMON-II 
(RFC 2021 [19]) does not currently capture the direction of the flow. 
This MIB module provides the capability to define an interface based 
on the specific direction of the flow. 


This section provides an overview and background of how to use this 
MIB module. 
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3.1. Circuit Concepts 
There are multiple MIB modules that define circuits. Three commonly 
used MIB modules are FRAME-RELAY-DTE-MIB (RFC 2115) [20], FRNETSERV- 
MIB (RFC 2954) [18], and ATM-MIB (RFC 2515) [22]. These define 


management objects for frame relay DTEs, frame relay services, and 
ATM respectively. Each of these MIB modules contain the ability to 
add or delete circuits; however, none create a specific ifEntry for 
a circuit. The reason for this is that there are potentially 
multiple circuits and not every circuit needs to be managed as an 
individual interface. For example, not every circuit on a device 
needs to be monitored with RMON and not every circuit needs to be 
included as an individual circuit for routing. Further, the 
Interfaces Group MIB (RFC 2863) [17] strongly recommends that 
conceptual rows not be added to the ifTable for virtual circuits. 


The rationale for creating conceptual rows in the ifTable for these 
circuits is that there is a need for their use in either management 
of routing or monitoring of data. Both of these functions require 
mapping to an ifIndex. 


This MIB module is designed such that only those circuits that 
require an ifIndex need be added to the ifTable. This prevents 
over-populating the ifTable with useless or otherwise unused indices. 


While this document often refers to ATM and frame relay, it is not 
specifically designed for only those types of circuits. Any circuit 
that is defined in a MIB module but does not have its own ifIndex MAY 
be added with this MIB module. 

3.2. Theory of Operation 

3.2.1. Creation Process 
In some cases, devices will automatically populate the rows of 
ciCircuitTable as circuits are created or discovered. However, in 
many cases, it may be necessary for a network manager to manually 
create rows. 
Manual creation of rows requires the following steps: 


1) Locate or create the circuit that is to be added on the device. 


2) Create a row in ciCircuitTable for each flow type that is 
required. 


The first step above requires some knowledge of the circuits that 
exist on a device. Typically, logical ports have entries in the 
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ifTable. If, for example, the ifType for the logical port is 
frameRelay (32), the circuits can be located in the frCircuitTable of 
the Frame Relay DTE MIB (FRAME-RELAY-DTE-MIB) [18]. If, as another 
example, the ifType for the logical port is frameRelayService (44), 
the circuits can be located in the frPVCEndptTable of the Frame Relay 


Service MIB (FRNETSERV-MIB) [20]. If, as a final example, the ifType 
for the logical port is aal5(49), the circuits can be located in the 
aal5VccTable of the ATM MIB (ATM-MIB) [22]. An entry describing the 


circuit MUST exist in some table prior to creating a row in 
ciCircuitTable. The object identifier that MUST be used in the 
circuit definition is the lexicographically smallest accessible OID 
that fully describes the the circuit. 


3.2.2. Destruction Process 
3.2.2.1. Manual Row Destruction 


Manual row destruction is straight forward. Any row can be destroyed 
and the resources allocated to it are freed by setting the value of 
its status object (ciCircuitStatus) to destroy(6). It should be 
noted that when ciCircuitStatus is set to destroy(6) all associated 
rows in the ifTable and in cilfMapTable will also be destroyed. This 
process MAY trigger further row destruction in other tables as well. 


3.2.2.2. Automatic Row Destruction 


Rows in the tables MAY be destroyed automatically based on the 
existence of the circuit on which they rely. When a circuit no 
longer exists in the device, the data in the tables has no relation 
to anything known on the network. For this reason, rows MUST be 
removed from this table as soon as it is discovered that the 
associated circuits no longer exist. The effects of automatic row 
destruction are the same as manual row destruction. 


3.2.3. Modification Process 


Since no objects in the MIB module can be changed once rows are 
active, there are no modification caveats. 


3.2.4. Persistence of Data 


Each row in the tables of this MIB module relies on information from 
other MIB modules. The rules for persistence of the data SHOULD 
follow the same rules as those of the underlying MIB module. For 
example, if the circuit defined by ciCircuitObject would normally be 
stored in non-volatile memory, then the ciCircuitEntry SHOULD also be 
non-volatile. 
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4. Relation to Other MIB Modules 

4.1. Frame Relay DTE MIB 
There is no required relation to the Frame Relay DTE MIB beyond the 
fact that rows in the frCircuitTable MAY be referenced. However, if 
frCircuitLogicallIfIndex is being used to represent the same 
information as a ciCircuitEntry with a value of ciCircuitFlow equal 
to both(3), the implementation MAY use the same ifIndex. 

4.2. Frame Relay Service MIB 


There is no explicit relation to the Frame Relay Service MIB beyond 
the fact that a rows in the frPVCEndptTable MAY be referenced. 


4.3. ATM MIB 


There is no explicit relation to the ATM MIB beyond the fact that 
rows in multiple tables may be referenced. 


4.4. Interfaces Group MIB 

4.4.1. Interfaces Table (ifTable, ifXtable) 
The following specifies how the Interfaces Group defined in the IF- 
MIB will be used for the management of interfaces created by this MIB 


module. 


Values of specific ifTable objects for circuit interfaces are as 


follows: 

Object Name Value of Object 

ifIndex Each entry in the circuit table is represented by an 
ifEntry. The value of ifIndex is defined by the agent 
such that it complies with any internal numbering 
scheme. 

ifType The value of ifType is specific to the type of circuit 


desired. For example, the value for frame relay 
virtual circuits is frDlciEndPt (193) and the value for 
ATM virtual circuits is atmVciEndPt (194). If the 
circuit is to be used in RMON, propVirtual (53) SHOULD 
NOT be used. 
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ifMtu 


ifSpeed 


ifPhysAddress 


ifInOctets 


ifInUcastPkts 


ifInDiscards 


ifInErrors 


ifOutOctets 
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Set to the size in octets of the largest packet, frame 
or PDU supported on the circuit. If this is not known 
to the ifMtu object shall be set to zero. If the 
circuit is not modeled as a packet-oriented interface, 
this object SHOULD NOT be supported and result in 
noSuchInstance. 


The peak bandwidth in bits per second available for 
use. This will equal either the ifSpeed of the 
logical link if policing is not enforced or the 
maximum information rate otherwise. If neither is 
known, the ifSpeed object shall be set to zero. 


This will always be an octet string of zero length. 


The number of octets received by the network (ingress) 
for this circuit. This counter should count only 
octets included the header information and user data. 
If the device does not support statistics on the 
circuit, this object MUST NOT be supported and result 
in noSuchInstance. 


The unerrored number of frames, packets or PDUs 
received by the network (ingress) for this circuit. 
If the device does not support statistics on the 
circuit, this object MUST NOT be supported and result 
in noSuchInstance. 


The number of received frames, packets or PDUs for 
this circuit discarded due to ingress buffer 
congestion and traffic policing. If the device does 
not support statistics on the circuit, this object 
MUST NOT be supported and result in noSuchInstance. 


The number of received frames, packets or PDUs for 
this circuit that are discarded because of an error. 
If the device does not support statistics on the 
circuit, this object MUST NOT be supported and result 
in noSuchInstance. 


The number of octets sent by the network (egress) for 
this circuit. This counter should count only octets 
included the header information and user data. If the 
device does not support statistics on the circuit, 
this object MUST NOT be supported and result in 
noSuchInstance. 
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ifOutUcastpkts The number of unerrored frames, packets or PDUs sent 
by the network (egress) for this circuit. If the 
device does not support statistics on the circuit, 
this object MUST NOT be supported and result in 
noSuchInstance. 


ifOutDiscards The number of frames, packets or PDUs discarded in the 
egress direction for this circuit. Possible reasons 
are as follows: policing, congestion. If the device 
does not support statistics on the circuit, this 
object MUST NOT be supported and result in 
noSuchInstance. 


ifOutErrors The number of frames, packets or PDUs discarded for 
this circuit in the egress direction because of an 
error. If the device does not support statistics on 
the circuit, this object MUST NOT be supported and 
result in noSuchInstance. 


ifInBroadcastPkts 
If the device does not support statistics on the 
circuit, this object MUST NOT be supported and result 
in noSuchInstance. 


ifOutBroadcastPkts 
If the device does not support Broadcast packets on 
the circuit, this object should not be supported and 
result in noSuchInstance. 


ifLinkUpDownTrapEnable 
Set to false(2). Circuits often have a predefined 
notification mechanism. In such instances, the number 
of notification sent would be doubled if this were 
enabled. 


ifPromiscuousMode 
Set to false(2). If the circuit is not modeled as a 
packet-oriented interface, this object SHOULD NOT be 
supported and result in noSuchInstance. 


ifConnectorPresent 
Set to false(2). 


All other values are supported as stated in the IF-MIB documentation. 
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4.4.2. Stack Table (ifStackTable) 
This section describes by example how to use ifStackTable to 
represent the relationship between circuit and logical link 


interfaces. 


Example 1: Circuits (C) on a frame relay logical link. 


+---+------ +------ +---+ 
| Frame Relay Service | 
+---------- +---------- + 
+---------- | ---------- + 
| Physical Layer | 
+--------------------- + 


The assignment of the index values could for example be (for a V35 
physical interface): 


ifIndex Description 


1 frDlciEndPt (type 193) 
2 frDlciEndPt (type 193) 
3 frDlciEndPt (type 193) 
4 frameRelayService (type 44) 
5 v35 (type 33) 


The ifStackTable is then used to show the relationships between each 
interface. 


HigherLayer LowerLayer 


OP wWNrFOOO 
our BP BPWNE 


In the above example the frame relay logical link could just as 
easily be of type frameRelay(32) instead. 
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Example 2: Circuits (C) on a AALS logical link. 


Ic] [c] [cl 
+-+-+ +-+-+ +-+-+ 
| | | 
+---4------ +------ +---+ 
| AAL5 Layer | 
+---------- +---------- + 
| 
+---------- +---------- + 
ATM Layer 
+--------------------- + 
| 
+---------- +---------- + 
| Physical Layer | 
+--------------------- + 


The assignment of the index values could for example be (for a DS3 
physical interface): 


ifIndex Description 


1 atmVciEndPt (type 194) 
2 atmVciEndPt (type 194) 
3 atmVciEndPt (type 194) 
4 aal5 (type 49) 
5 atm (type 37) 
6 ds3 (type 30) 


The ifStackTable is then used to show the relationships between each 
interface. 


HigherLayer LowerLayer 


NOP WNHNR OOO 
ONnNU ARP RBWNE 
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4.5. Other MIB Modules 


There is no explicit relation to any other media specific MIB module 
beyond the fact that rows in multiple tables may be referenced. 


5. Structure of the MIB Module 


The CIRCUIT-IF-MIB consists of the following components: 


o ciCircuitTable 


o ciIfMapTable 


Refer to the compliance statement defined within for a definition of 


what objects MUST be implemented. 


5.1. ciCircuitTable 


The ciCircuitTable is the central control table for operations of the 
Circuit Interfaces MIB. It provides a means of mapping a circuit to 
its ifIndex as well as forcing the insertion of an ifIndex into the 
ifTable. The agent is responsible for managing the ifIndex itself 
such that no device dependent indexing scheme is violated. 


A row in this table MUST exist in order for a row to exist in any 


other table in this MIB module. 


5.2. ciIfMapTable 


This table maps the ifIndex back to the circuit that it is associated 


with. 
6. Object Definitions 
CIRCUIT-IF-MIB DEFINITIONS ::= BEGIN 


IMPORTS 
MODULE-IDENTITY, OBJECT-TYPE, 
mib-2, Gauge32 
TEXTUAL-CONVENTION, RowStatus, 
TimeStamp, RowPointer, StorageType 
MODULE-COMPLIANCE, OBJECT-GROUP 
ifIndex, InterfaceIndex 


circuitIfMIB MODULE-IDENTITY 


FROM SNMPv2-SMI 


FROM SNMPv2-TC 
FROM SNMPv2-CONF 
FROM IF-MIB; 


LAST-UPDATED "200201030000Zz" -- January 3, 2002 
ORGANIZATION "IETF Frame Relay Service MIB Working Group" 


CONTACT-INFO 
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"IETF Frame Relay Service MIB (frnetmib) Working Group 


WG Charter: http://www.ietf.org/html.charters/ 
frnetmib-charter.html 

WG-email: frnetmib@sunroof.eng.sun.com 

Subscribe: frnetmib-request@sunroof.eng.sun.com 


Email Archive: ftp://ftp.ietf.org/ietf-mail-archive/frnetmib 


Chair: Andy Malis 
Vivace Networks 
Email: Andy.Malis@vivacenetworks.com 


WG editor: Robert Steinberger 

Paradyne Networks and 

Fujitsu Network Communications 
Email: robert.steinberger@fne.fujitsu.com 


Co-author: Orly Nicklass 
RAD Data Communications Ltd. 
EMail: Orly_n@rad.co.il" 
DESCRIPTION 
"The MIB module to allow insertion of selected circuit into 
the ifTable." 
REVISION "2002010300002" -- January 3, 2002 
DESCRIPTION 
"Initial version, published as RFC 3201" 
::= { mib-2 94 } 


-- Textual Conventions 


CiFlowDirection ::= TEXTUAL—CONVENTION 
STATUS current 
DESCRIPTION 
"The direction of data flow thru a circuit. 


transmit(1) - Only transmitted data 
receive(2) - Only received data 
both (3) - Both transmitted and received data." 


SYNTAX INTEGER { 
transmit (1), 
receive(2), 
both (3) 


ciObjects OBJECT IDENTIFIER ::= { circuitIfMIB 1 } 
ciCapabilities OBJECT IDENTIFIER { circuitIfMIB 2 } 
ciConformance OBJECT IDENTIFIER { circuitIfMIB 3 } 
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-- The Circuit Interface Circuit Table 
-—- This table is used to define and display the circuits that 
-- are added to the ifTable. It maps circuits to their respective 


-- ifIndex values. 


ciCircuitTable OBJECT-TYPE 


SYNTAX SEQUENCE OF CiCircuitEntry 
MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 


"The Circuit Interface Circuit Table." 
::= { ciObjects 1 } 


ciCircuitEntry OBJECT-TYPE 


SYNTAX CiCircuitEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"An entry in the Circuit Interface Circuit Table." 
INDEX { ciCircuitObject, ciCircuitFlow } 


:= { ciCircuitTable 1 } 


CiCircuitEntry ::= 
SEQUENCE { 


-- Index Control Variables 


ciCircuitObject RowPointer, 
ciCircuitFlow CiFlowDirection, 
ciCircuitStatus RowStatus, 


-- Data variables 


ciCircuitIfIndex InterfaceIndex, 
ciCircuitCreateTime TimeStamp, 


-- Data Persistence 


ciCircuitStorageType StorageType 
} 


ciCircuitObject OBJECT-TYPE 


SYNTAX RowPointer 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 


"This value contains the RowPointer that uniquely 
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describes the circuit that is to be added to this table. 
Any RowPointer that will force the size of OBJECT 
IDENTIFIER of the row to grow beyond the legal limit 
MUST be rejected. 


The purpose of this object is to point a network manager 
to the table in which the circuit was created as well as 
define the circuit on which the interface is defined. 


Valid tables for this object include the frCircuitTable 
from the Frame Relay DTE MIB(FRAME-RELAY-DTE-MIB), the 
frPvCEndptTable from the Frame Relay Service MIB 
(FRNETSERV-MIB), and the aal5VccTable from the ATM MIB 
(ATM MIB). However, including circuits from other MIB 
tables IS NOT prohibited." 

::= { ciCircuitEntry 1 } 


ciCircuitFlow OBJECT-TYPE 


SYNTAX CiFlowDirection 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 


"The direction of data flow through the circuit for which 
the virtual interface is defined. The following define 
the information that the virtual interface will report. 


transmit(1) - Only transmitted frames 
receive(2) - Only received frames 
both (3) - Both transmitted and received frames. 


It is recommended that the ifDescr of the circuit 
interfaces that are not both(3) SHOULD have text warning 
the operators that the particular interface represents 
only half the traffic on the circuit." 

::= { ciCircuitEntry 2 } 


ciCircuitStatus OBJECT-TYPE 


SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 


"The status of the current row. This object is 
used to add, delete, and disable rows in this 
table. When the status changes to active(1), a row 
will also be added to the interface map table below 


and a row will be added to the ifTable. These rows 
SHOULD not be removed until the status is changed 
from active(1). The value of ifIndex for the row that 
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is added to the ifTable is determined by the agent 
and MUST follow the rules of the ifTable. The value 
of ifType for that interface will be frDlciEndPt (193) 
for a frame relay circuit, atmVciEndPt (194) for an 
ATM circuit, or another ifType defining the circuit 
type for any other circuit. 


When this object is set to destroy(6), the associated 
row in the interface map table will be removed and the 
ifIndex will be removed from the ifTable. Removing 
the ifIndex MAY initiate a chain of events that causes 
changes to other tables as well. 


The rows added to this table MUST have a valid object 
identifier for ciCircuitObject. This means that the 
referenced object must exist and it must be in a table 
that supports circuits. 


The object referenced by ciCircuitObject MUST exist 
prior to transitioning a row to active(1l). If at any 
point the object referenced by ciCircuitObject does not 
exist or the row containing it is not in the active(1) 
state, the status SHOULD either age out the row or 
report notReady(3). The effects transitioning from 
active(1l) to notReady(3) are the same as those caused 
by setting the status to destroy (6). 


Each row in this table relies on information from other 
MIB modules. The rules persistence of data SHOULD follow 
the same rules as those of the underlying MIB module. 
For example, if the circuit defined by ciCircuitObject 
would normally be stored in non-volatile memory, then 
the row SHOULD also be non-volatile." 

::= { ciCircuitEntry 3 } 


ciCircuitIfIndex OBJECT-TYPE 


SYNTAX InterfaceIndex 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"The ifIndex that the agent assigns to this row." 
::= { ciCircuitEntry 4 } 


ciCircuitCreateTime OBJECT-TYPE 


SYNTAX TimeStamp 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
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"This object returns the value of sysUpTime at the time 
the value of ciCircuitStatus last transitioned to 
active(1). If ciCircuitStatus has never been active(l), 
this object SHOULD return 0." 

::= { ciCircuitEntry 5 } 


ciCircuitStorageType OBJECT-TYPE 


SYNTAX StorageType 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 


"The storage type used for this row." 
::= { ciCircuitEntry 6 } 


—- The Circuit Interface Map Table 


-- This table maps the ifIndex values that are assigned to 
—-- rows in the circuit table back to the objects that define 
-- the circuits. 


cilfMapTable OBJECT-TYPE 


SYNTAX SEQUENCE OF CilfMapEntry 
MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 


"The Circuit Interface Map Table." 
::= { ciObjects 2 } 


cilfMapEntry OBJECT-TYPE 
SYNTAX CilfMapEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"An entry in the Circuit Interface Map Table." 
INDEX { ifIndex } 
::= { cilfMapTable 1 } 


CilfMapEntry ::= 
SEQUENCE { 


-- Mapped Object Variables 


cilfMapObject RowPointer, 
cilfMapFlow CiFlowDirection 


} 


cilfMapObject OBJECT-TYPE 
SYNTAX RowPointer 
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MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"This value contains the value of RowPointer that 
corresponds to the current ifIndex." 

::= { cilfMapEntry 1 } 


cilfMapFlow OBJECT-TYPE 


SYNTAX CiFlowDirection 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"The value contains the value of ciCircuitFlow that 
corresponds to the current ifIndex." 
:= { cilfMapEntry 2 } 


—- Change tracking metrics 


cilfLastChange OBJECT-TYPE 


SYNTAX TimeStamp 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"The value of sysUpTime at the most recent change to 
ciCircuitStatus for any row in ciCircuitTable." 
::= { ciObjects 3 } 


cilfNumActive OBJECT-TYPE 
SYNTAX Gauge32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"The number of active rows in ciCircuitTable." 
::= { ciObjects 4 } 


-- Conformance Information 


ciMIBGroups OBJECT IDENTIFIER 
ciMIBCompliances OBJECT IDENTIFIER 


{ ciConformance 1 } 
{ ciConformance 2 } 


-—- Compliance Statements 


ciCompliance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION 
"The compliance statement for SNMP entities 
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which support of the Circuit Interfaces MIB module. 
This group defines the minimum level of support 
required for compliance." 


MODULE -- this module 
MANDATORY-GROUPS { ciCircuitGroup, 
cilfMapGroup, 
ciStatsGroup } 
OBJECT ciCircuitStatus 
SYNTAX INTEGER { active(1l) } -- subset of RowStatus 
MIN-ACCESS read-only 
DESCRIPTION 


"Row creation can be done outside of the scope of 

the SNMP protocol. If this object is implemented with 
max-access of read-only, then the only value that MUST 
be returned is active(1)." 


OBJECT ciCircuitStorageType 
MIN-ACCESS read-only 
DESCRIPTION 


"It is legal to support ciCircuitStorageType as read- 
only as long as the value reported in consistent 

with the actual storage mechanism employed within the 
agent." 


::= { ciMIBCompliances 1 } 


-- Units of Conformance 
ciCircuitGroup OBJECT-GROUP 
OBJECTS { 
ciCircuitStatus, 
ciCircuitIfIndex, 
ciCircuitCreateTime, 
ciCircuitStorageType 
} 
STATUS current 
DESCRIPTION 
"A collection of required objects providing 
information from the circuit table." 
::= { ciMIBGroups 1 } 


cilfMapGroup OBJECT-GROUP 
OBJECTS { 
cilfMapObject, 
cilfMapFlow 
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STATUS current 
DESCRIPTION 
"A collection of required objects providing 
information from the interface map table." 
::= { ciMIBGroups 2 } 


ciStatsGroup OBJECT-GROUP 
OBJECTS { 
cilfLastChange, 
cilfNumActive 
} 
STATUS current 
DESCRIPTION 
"A collection of statistical metrics used to help manage 
the ciCircuitTable." 
::= { ciMIBGroups 3 } 
END 
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Security Considerations 


There are a number of management objects defined in this MIB that 
have a MAX-ACCESS clause of read-write and/or read-create. Such 
objects may be considered sensitive or vulnerable in some network 
environments. The support for SET operations in a non-secure 
environment without proper protection can have a negative effect on 
network operations. 


SNMPv1 by itself is not a secure environment. Even if the network 
itself is secure (for example by using IPSec), even then, there is no 
control as to who on the secure network is allowed to access and 
GET/SET (read/change/create/delete) the objects in this MIB. 


It is recommended that the implementers consider the security 
features as provided by the SNMPv3 framework. Specifically, the use 
of the User-based Security Model RFC 2274 [12] and the View-based 
Access Control Model RFC 2275 [15] is recommended. 


It is then a customer/user responsibility to ensure that the SNMP 
entity giving access to an instance of this MIB, is properly 
configured to give access to the objects only to those principals 
(users) that have legitimate rights to indeed GET or SET 
(change/create/delete) them. 


IANA Considerations 


New ifTypes defined specifically for use in this MIB module SHOULD be 
in the form of ***EndPt. This is similar to frDlciEndPt (193) and 
atmVciEndPt (194) which are already defined. 
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This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
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developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
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BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
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